home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Libris Britannia 4
/
science library(b).zip
/
science library(b)
/
PACKET
/
WNOS4DOC.ZIP
/
WNOS4DOC.EXE
/
WNOS3MAN.TXT
< prev
next >
Wrap
Text File
|
1992-04-04
|
54KB
|
1,496 lines
DB3FL WAMPES NOS (WNOS) Version 3 User Guide
Mike Chace (G6DHU)
Document Version 1.4 (April 1992)
WNOS3 is a new "hybrid" NOS and combines functionality
from KA9Q, G1EMM, and PA0GRI NOS with a AX.25 front-end
derived from the German WAMPES system.
It features Data Compression, a more friendly User
Interface and Mailbox, AX.25 Autorouter and a Chat node
that can be used to connect IP hosts together like
PacketCluster.
WNOS supports the usual range of TNC drivers (KISS, DRSI,
SCC etc) as well as all the well established TCP services;
Telnet, FTP, POP, SMTP, NNTP, and TTYlink. It has no need
for RSPF and RIP since the WAMPES front-end deals with the
auto-routing. WNOS periodically saves all routing
information (IP, ARP and AX.25) to all known hosts making
it a truly dynamic system.
This manual is a guide to the new features in WNOS mainly
designed for users of other NOS versions (G1EMM, PA0GRI
etc) who might be trying WNOS for the first time. You
should also have received a copy of the WNOS3 command
reference with the UK release package.
THIS DOCUMENT *MUST* BE INCLUDED IN ANY COPY YOU MAKE OF
WNOS AND GIVE TO SOMEONE ELSE.
1. What's New in WNOS3 ?
1.1. The User Interface
1.1.1. The Status Line
Perhaps the first thing that you'll notice after loading WNOS3 is the
command screen.
The top line of the screen is permanently occupied by the Status Line.
The line can be configured for either colour or mono displays (see the
"attribute" command).
In use, the status line will look something like this
WNOS3 | 22:02 | CMD | 1:R:U:GB7IMB-2 2:g4wrw 3:R:44.131.17.11 4:Chat
A B C D E F G
A) Is the Program Name
B) Is the current time
C) Shows the program "mode"
CMD = Command mode (at the program prompt)
TRA = Trace Screen
* = Session mode
D) Shows session 1 status. Upper case denotes a session to either
an AX.25 station or a NET/ROM host (in this case GB7IMB-2).
The "R" denotes that the session is in "record" mode, copying
session input and output to a file.
The "U" denotes that the session is in "upload" mode and a file is
being sent to GB7IMB-2.
E) Denotes an TCP/IP based connection to a host. TCP/IP hosts are
always displayed in lower case.
F) Session 3 is connected to TCP/IP host on address 44.131.17.11
and is in "record" mode.
G) Session 4 is a local Chat session (someone typed "chat" from the
mailbox). IP Stations telnet'ed/ttylink'ed to your Chat port (TCP
port 87) don't display as "Chat", instead the address of that IP
station is shown.
Connections to you local bbs (that is, you typed "bbs" at the program
prompt) are shown in the same format and are marked as LocBBS.
1.1.2. The Program Prompt
Instead of the old net> prompt, WNOS3 displays you hostname eg.
g6dhu.ampr.org>
1.1.3. Moving Between Sessions
WNOS3 differs from all previous version of NOS in that moving between
sessions is now accomplished through use of the Function keys....
F1 to F8 : Select sessions 1 through to 8
F9 : Toggles between the "Trace" screen
and the last selected screen (session or command)
F10 : Return to Command Mode
ESCAPE : Return to Command Mode (See the "escape" command
ALT+F10 : Select the Trace screen - No Toggling.
The use of the return key is two fold depending on whether you are in
the Trace or the Command screen.
ENTER : From Command Mode - Switches into the last selected
session
ENTER : From the Trace Screen - Switches into the last selected
session
Please note that in command mode, with no active sessions, pressing
ENTER will have NO EFFECT. It's a bit disconcerting at first but you'll
get used to it.
All trace output goes into the Trace Screen (selected by F9). It no
longer scribbles over sessions or the command display.
1.1.4. Editing Characters
The following special keys can be used to edit or redisplay input either
to a session or at the prompt.
Control-B : Fill rest of command line upto end
of last input (see below)
Control-R : Recalls the previous (complete) line
Control-U : Kills the current line
Control-W : Deletes the previous word in the current line
Up-Arrow : Scrolls backwards through past input
Down-Arrow : Scrolls forwards through past input
Control-B needs an example. Say the last (valid) command you typed was
'tcp status'. If you then begin to type a new line and press Control-B,
the rest of the previous line is added to the new one.
g6dhu.ampr.org> tcp status
<output from command>
g6dhu.ampr.org> ax2 <type Control-B>
gives the input line
g6dhu.ampr.org>ax2 status
Input history is kept separate for each session and the command window.
1.1.5. Session Notification
The status line session summary (eg 2:g4wrw) will blink if that session
receives incoming data and will continue to do so until you select that
session. Once you close session, the status line summary will be deleted
and all other summaries move one to the left.
Sessions closed by the remote end will of course remain (blinking) on
the status line until you look at them. This is a useful feature,
allowing someone to drop you a quick message, which you won't lose!
Incoming connections to your 'Chat' port will ring a "bell" to alert you
to the fact that someone wishes to chat to you. This happens according
to the setting of the "bell" command and whether or not you are
"attended" (see below).
Input to sessions of type Telnet, Chat, Convers, AX.25 and NET/ROM is in
a pseudo "split screen" mode. The text you type ALWAYS appears at the
bottom of the screen and allows the other persons text to appear as you
are preparing that line. Your text is shown in "normal" (light) text and
that from the remote end in "intensified" (bright) text. You can use the
cursor (up and down arrow keys) to recall past input and scroll through
it whilst preparing outgoing text.
On selecting a session, you are taken into that session's "window"
(which holds its own, separate input history) and the Status Line entry
for the current session is shown in "normal" text (white on black). The
other, unselected Status Line session entries remain in "inverse" text
(Black on white)
1.1.5.1. Colour Displays
The above discussion holds on Mono displays (set "attribute mono"). On
Colour displays (set "attribute col") Status line columns A, B and C are
shown in Red.
Further columns (session indicators) are shown in Blue. The arrival of
new data to an unselected session is indicated by it having an inverse
Grey bar.
The current session is in yellow text upon a Blue background, all other
sessions are shown in Grey text upon a Blue background.
Another feature unique to WNOS3 is that automatic wrapping of outgoing
text is enabled in sessions. You can specify a line length limit (see
the "wrap" command), if you type beyond this limit, the next space will
force the line to be transmitted and the rest of your input line over
the line length limit is put at the start of the next line. This means
that you don't have to think about pressing return all the time as you
near the end of a line. WNOS detects when you have reached the end of
the line and sends that text out without intervention. It also
eliminates a messy screen at the remote end of the link where lines go
over the 80th column.
1.2. The Auto-Router
One of the other major changes to WNOS3 is that the NOS AX.25 front-end
has been replaced by that from the German WAMPES system. The WAMPES
front-end allows full AX.25 auto-routing as well as saving of all
routing information (IP, ARP and AX.25 routes) to disk at regular
intervals.
Unfortunately, the AX.25 auto-router is only of real use in IP networks
where nodes are directly connected. By this is I mean that other hosts
are reachable through a direct AX.25 connection (VC or datagram mode) or
using AX.25 across a digipeated path. This is because the WAMPES system
was primarily designed to work with FlexNet, a networking system in
widespread use throughout Europe (but not in the UK hihi). FlexNet is a
fast system with 1200bps and 9600bps user access ports and 9600bps
backbone links and works on the principle of fixed routes between nodes
using hop-to-hop acknowledgements (looks like normal digipeating to end
users).
The auto-router is however still useful over here in the UK. See the
"ax25 route" commands in the Command Summary for details of the
autorouter.
1.2.1. Using the Auto router
I should also note that the AX.25 auto router can also auto route
digipeated packets thereby allowing very effective crossband operation.
For example, let's imagine that a WNOS3 node local to you has two
interfaces one on 70cm and the other on 2m. That system will of course
get to know the AX.25 paths to stations on both interfaces. You can then
set up connections via the local node which enter on one frequency and
get digipeated on the other. For instance, I have a local WNOS3 node,
G4OTJ-2 which has a 70cm and 2m interface. G4OTJ-2 knows that there is a
path to the KA-node G1WQU-8 on 70cm. If I am on 2m, I can reach G1WQU-8
without knowing how the crossband connection (and if there are any digis
involved) is made simply by using the connect command
g6dhu.ampr.org> connect 144 g1wqu-8 g4otj-2
So I send a connect request to G1WQU-8 via G4OTJ-2 and the autorouter at
G4OTJ-2 works out how to get to G1WQU-8! And, of course, since my
autorouter will now have stored the path to G1WQU-8, the next time I
want to connect to that station, all I need type is
g6dhu.ampr.org> connect g1wqu-8
WNOS3 does away with the need for you to remember how to get to places
and lets the software do it all automatically.
As you can see, it makes for a very powerful and flexible system. For
further details see the "ax25 digipeat" command.
1.3. Dynamic Route Save
Each time an IP frame is processed by an WNOS3 system, the machine
records the following information in it's various routing tables
1) An IP route entry
2) An ARP entry
3) An AX.25 Path entry (if the IP frame arrived via AX.25)
The system therefore dynamically alters its knowledge of routing to
other IP hosts and records ALL information necessary to reach that host.
For instance, if a node normally reaching you via NET/ROM manages to
deliver a frame via direct AX.25 and say over your UHF rather than VHF
interface, your system has saved all this information and can alter its
return path in response. Other NOS systems will not be able to do so!
Each of the routing tables dynamically written to are saved to disk at
regular intervals (see the 'route save', 'ax25 route save' and 'arp
save' commands). These files are then read from disk the next time you
start up and so you never lose this routing information.
1.4. Compression
WNOS3 is unique in that it is the first NOS variant to make use of a NOS
feature that has long existed, but never been used before - data
compression.
In the present release, both e-mail and telnet based sessions (eg chat)
have the ability to send and receive compressed data using a method that
is completely transparent to the users. It is also backward comaptible
with non-compressed systems so if you're the only one using WNOS3 you'll
still be able to everything you did before.
WNOS3 uses the LZW (Lempel-Ziv) data compression method which is used to
"squash" text data using LZW coding before it is sent out over the air.
Since text contains a lot of redundant infomation such as tabs and
spaces LZW can often compress data to upto 40% of its original size. The
basic advantages are obvious - you send less real data which improves
performance where it's most felt (across a slow RF link) and you're also
thereby doing the network a favour by reducing traffic. Obviously, there
is a slight penalty in performace at each end of the link in unpacking
the data and converting it back into human-readable text but that is
small in comparison with the time it takes to send the data out over the
air.
Line-by-line protocols such as telnet are compressed when you press the
return key at the end of the line and then sent out to the remote end.
Message (file) based protocols such as SMTP negotiate with the other end
of the link to see if it will accept compressed mail. If you "trace" an
outgoing SMTP session, you will see that the machines greet each other
in the usual way but a sending WNOS node will then send the command
"XLZW". If the other end is also a WNOS3 node it responds with "250 Ok"
and the mail (and any subsequent commands eg QUIT) are sent out in
compressed form. On completing the mail transfer, the remote end will
then uncompress the mail before writing it to the appropriate mailbox.
Should the remote end not be a WNOS3 node, it will respond to the XLZW
command with "550 Command Unrecognised" and the sending end will forward
mail as normal.
LZW compression is a mainly experimental feature in WNOS3 and may well
be extended to NNTP, POP and convers for example if it found useful. If
you find it so please drop me or Mike, DB3FL, a line. I think it is a
great step forward and should prove useful on marginal links, of which,
there are (let's face it) plenty in the UK.
1.5. Convers Node and Cluster Mode
1.5.1. What Is a Convers Node ?
The convers (pronounced like converse) node is much like the G8BPQ
"CHAT" system or TheNet Mini-Convers and allows round-table QSOs between
a number of users connected to it. If you've never used a Chat node
before, it's best imagined in the following way.
You and your fellow hams all connect to the convers node. On connecting,
you are asked to login so that the system knows your name (or callsign)
and can then send messages to you. The convers node has a number of
"channels" to which 1, 2 or more people can be connected, talking either
to each other as a group or sending private messages to each other. So
you can think of it as a multi-user "conferencing" system. You can QSY
to other channels if you want a simple private conversation with another
person and other users can invite you into the "net" on their channel.
The convers node software handles all the conversations on each channel
independently and sends the conversation(s) out to each user connected.
1.5.2. The WNOS Convers System
WNOS3 supports two distinct convers modes which I'll refer to from now
on as "local" and "cluster" mode. I'll cover basic use of the system in
the section on local access below. The behaviour under Cluster access
being exactly the same.
To enable your convers server you must put the line
start convers
somewhere in your autoexec.nos file.
1.5.2.1. Local Mode
Any WNOS3 system can enable it's own internal convers node (or server)
(see the "start convers" command). The convers server lives on TCP port
number 3600.
Your local convers server can be accessed in two ways...
1) Remote users telnet to your port 3600 (ie they type 'telnet
g6dhu 3600')
2) Remote users (including AX.25 users) can type 'convers' at your
mailbox
prompt.
You can of course login to your local server by typing (for example)
g4otj.ampr.org> telnet g4otj 3600
Users connecting from the mailbox get told to login using the convers
"/N <name>" command but if you login locally by telnet you'll need to do
this before the server will respond and you will then get the convers
login banner.
Once logged in, you can use the / commands (see /HELP or /H) for help to
inquire about the state of the system, who is logged in etc.
Private messages to a named user are sent using the /MSG or /WRITE
commands (for example)...
/M john Hi there John, Just noticed you login!
Anything that you type without a / command will be sent to all users
logged into your channel (change channels with the /CHANNEL or /C
command).
Chatter from your channel is sent to you like this
<john>: Did you see that there is a new TCP/IP user in the area ?
<dave>: No, What's his callsign ?
<mike>: I think it's G6DHU
<dave>: No it isn't, it's G4WRW
<*pete*>: Who cares ?
etc
Notice that text directed to everybody on your channel has the ID of the
person who sent it eg <mike> (So that user logged in with (/n mike).
See also that user "pete" (the cynical one!) sent me a private message
(not seen by anyone else on the channel) indicated by the asterisks "*"
surrounding his user name.
1.5.2.2. Convers Cluster Mode
That last discussion took as its example convers users ALL logged into
the convers server running on YOUR machine. As I mentioned before,
TCP/IP users can do this either by telnetting to your port 3600 and
AX.25 Level 2 users can connect by typing the "convers" command whilst
logged into your mailbox.
WNOS3 has another very useful feature in which convers servers on a
number of WNOS3 nodes can be connected together. This brings about the
possibility of a distributed conference system much like TALK or
CONFERENCE as found in the PacketCluster system. This then enables users
logged in on one machine to transparently join in conversation with
other convers users who are logged on at a different machine. The
convers servers on each WNOS3 node talk to each other passing the
various messages back and forth.
To enable cluster mode, each WNOS3 node must set up a file in the WNOS
root directory (ie in the same place as the FTPUSERS file). This file
called "convers.cfg" identifies the name of your convers server and
defines the other convers servers you which to connect in cluster with.
PLEASE note that cluster servers **MUST** connect in a "daisy chain"
otherwise messages just "ping-pong" back and forth, growing each time
and probably resulting in network collapse. By "daisy chain", I mean
that if, for instance, you wish to interconnect 4 machines, the most
sensible configuration would be
g4wrw -> g4otj -> g0lxc -> g6dhu
so each machine connects to the next down the chain. All you need to do
is decide the network and AVOID ROUTING LOOPS AT ALL COST!
The format of convers.cfg is as follows
<your_host_name>
<remote_host_name> telnet|ax25|netrom
<remote_host_name> telnet|ax25|netrom
etc
<your_host_name> is the name of your machine eg g6dhu. You can enter
names of any length but only the first 8 characters are used.
<remote_host_name> is the name of the machine to connect to. Again,
typically you would use the domain name of a remote machine eg g4wrw.
With each remote host you must specify the protocol used to communicate
with that machine's convers server, either telnet, AX.25 or NET/ROM.
**Please note*** that only telnet method is currently supported, AX.25
and NET/ROM are likely to be added later. Please note that "telnet"
means the protocol to be used and that telnet connection can of course
be carried by AX.25 datagrams, virtual circuits or NET/ROM just the same
as any other telnet connection. AX.25 and NET/ROM connect methods will
use those protocols to send the convers messages (and therefore not use
TCP).
Example convers.cfg files for the above example cluster would be
At g6dhu - None needed (end node)
At g4otj - g4otj
g0lxc telnet
Obviously more complicated networks will require more "remote host"
entries. Imagine a star network for example.
On starting WNOS, the machine will read the convers startup file and
auto-connect to the remote machines specified in the file. No operator
intervention is needed. Once the connections are set up down the chain
all users can talk to each other. For instance, an AX.25 user could have
connected to g6dhu's mailbox, typed "convers" and be talking to someone
logged on all the way down the chain at g4wrw.
You can inquire on the state of cluster links to other machines by
logging into your local convers server and using the /LINKS (/L for
short) command.
1.6. A New Mailbox Interface
WNOS has a re-arranged mailbox interface. The most notable changes are
that the prompts are more informative and the "psuedo" NET/ROM node has
also been remodelled.
On logging into the mailbox, users will see the following...
[WNOS3-XH$]
g6dhu.ampr.org TCP/IP system.
Welcome to the G6DHU TCP/IP Mailbox!
The Escape Character is Control-X
Type C to Chat, ? for Command List, and 'S mike' to mail me
You have 1 message
(G6DHU) G6DHU de G6DHU>
Note first of all that the mailbox SID banner [WNOS3-XH$] now sports the
X flag to denote that it is capable of forwarding BBS mail in compressed
format (to compatible boxes).
The second line (fixed in the program) just announces your hostname to
others. The third, fourth and fifth lines are the contents of the
following command strings or files
motd (Message Of The Day) = Welcome to the G6DHU TCP/IP Mailbox!
host.hlp = The Escape Character is Control-X
mbox motd = Type C to Chat,... etc
The first and third of those above are standard (derived from the G1EMM
version of NOS) commands to set the "Messages of the day". The second is
a new feature whereby special messages for the mailbox can be specified
in file called "host.hlp" (see the Command Summary). If host.hlp is not
present, the program just sends the short string
? for Help
The final two lines of mailbox login text are of, a mail flag to show if
you have any mail waiting for you to read and of course, the mailbox
prompt. The prompt shows the following information
(G6XYZ) G6XYZ de G6DHU>
| | |
| | Mailbox Callsign
| User Callsign
Current Mail "area"
As expected, if the user changes mail area with the "area" command (eg
"area tcpip"), the prompt is updated to show (TCPIP) in the first prompt
field.
1.6.1. Mailbox Commands
This is the output from a ? request to the mailbox (short for HELP!!!).
(G6DHU) G6DHU de G6DHU> ?
Available commands:
area bye connect chat
convers download escape finger help
info kill list mheard nodes
nconnect path quit read send
telnet user upload what ?
(G6DHU) G6DHU de G6DHU>
As I mentioned before, perhaps the most obvious change is that the
NET/ROM node is now longer a separate part of the mailbox. All its
commands are available directly at the mailbox command line. Typing
"nodes" will show you a list of NET/ROM nodes known locally and a
NET/ROM connection can be made by typing "nconnect <nodecall>".
Other new things are the "path" command which displays a list of known
autorouter paths, or if a callsign is given too, the path to that
destination. As you might expect, users can just type "connect <call>"
to reach an autorouted destination. Digipeaters and interfaces are no
longer needed. A minor change is the "mheard" command which, as you
would expect shows the monitor heard list from your system.
Users returning from outbound connections are always returned to the
node on disconnection and are informed of this. For example
(G6DHU) G6DHU de G6DHU>convers
*** connected to 44.131.20.3:convers
conversd @ g6dhu $WNOS_Rev: A.2.17 $ Type /HELP for help.
/q
*** reconnected to G6DHU
(G6DHU) G6DHU de G6DHU>
In that case a user connected to the cluster and then quitted from it.
The same TNC-like connect message is sent when an AX.25 (raw or
autorouted) or NET/ROM connect is made. It should at least make non-
TCP/IP users a little less frightened of the technology!
The usual help scheme as found in other NOS version is included. "?"
will give the command list (as demonstrated above) and detailed help is
available by typing "h <command>" where <command> would be "path" for
instance. These help files live in the usual place (spool/help/*.hlp).
1.6.1.1. Mailbox Timers
The WNOS3 mailbox will disconnect a user after a period of inactivity
equal to the value you set for the ax25 t3 timer. For instance, "ax25 t3
180" sets the link inactivity timeout to 3 minutes (180 seconds) and on
logging in, users will see the extra message
Inactivity Timeout is 3 mins
(G6XYZ) G6XYZ de G6DHU>
The timeout is also dependent as to whether or not the link timer is
active (see the "ax25 t3disc" command). Users connected to the mailbox
via telnet (TCP port 23) do not receive this treatment.
1.6.1.2. Remote Sysop Mode
This has changed substantially in WNOS3. Remote sysop is useful if WNOS3
is running on a remote computer say on a hill-top site.
A password number key is entered (by the autoexec.nos file) via the
"sysop" command. A mailbox user wishing to login as remote sysop must
firstly have the correct FTPUSERs "sysop" permission bit set before
using the mailbox "@" command.
Entry is gained in the following manner (the pass number key is say
"sysop 12345").
1. Type @ at the mailbox prompt
2. The mailbox responds with 3 groups of 5 numbers in the prompt
89076, 77613, 11680>
3. The intended remote sysop must then calculate the password
according to the following formula.
Pass number = (Any number in first column * 1st number in key) +
(Any number in second column * 2nd number in key) +
(Any number in third column * 3rd number in key) +
(Any number in fourth column * 4th number in key) +
(Any number in fifth column * 5th number in key)
Eg (8 * 1) + (9 * 2) + (6 * 3) + (1 * 4) + (0 * 5) = 48
4. Type the password and you should be logged in
89076, 77613, 11680> 48
Net>
Successful login as sysop give you the remote sysop prompt as shown
above. Yes, yes, I know it's complicated but it's also *extremely*
difficult to break the key.
1.6.1.3. Mailbox Message Scrolling
By setting the "mbox more" command to "yes" you can enable a function
which passes mail messages to users on a page by page basis, prompting
for more (or a quit) and the end of each screenful. This function is
only active for users connecting to the mailbox via TCP (telnet to port
23).
1.6.1.4. Mail Signature
It is common Internet style that most mail messages end with a short
'signature' which gives details such as the senders home address, e-mail
address etc. WNOS can automatically add this signature to mail entered
into the system from the local bbs (the "bbs" command).
The signature lives in a file called <call>.sig situated in the
spool\signatur\ directory. The file SETUP.EXE contains an example
signature file (G6DHU.SIG) - the one I use here on my system. Remember
to keep it short and free of fancy graphics! Fancy graphics may look
great when viewed on the same type of machine from which they were
entered but display as meaningless crud on other systems!
Please note that the signature is only added to the end of messages that
are entered interactively into the bbs and not if an external mail
program (eg PCElm) is used. These programs add a signature file of their
own which usually is called something else and lives in another place!
1.7. The Not-So-Obvious Improvements
In this section I'll outline some of the improvements in WNOS3 over
other NOS versions or WNOS2 and any consequent changes in syntax. Please
refer to the Command Summary chapter for details of command syntax etc.
1.7.1. New AX.25 Features
Since the old NOS AX.25 front-end has been stripped out and replaced by
the WAMPES autorouter there have been some changes to ax25 parameters.
The AX.25 retransmission timer (ax25 t1) is now dynamically set by
measuring the round trip time of the connection. WNOS3 measures the time
it takes to get an ACKnowledgement (RR) packet back after sending an
information (I) frame, this time is known as the RTT. If this time is
recorded for a few sucessive packets, the value can be smoothed over
time to produce the SRTT (Smoothed Round Trip Time) of the connection.
WNOS3 sets the T1 timer to this value and adjusts it as conditions
change and a new SRTT emerges. The result should be a more efficient
connection.
MAXFRAME (ax25 maxframe) is now also dynamically set. The initial value
is set to the value specified in the "ax25 maxframe" command. The
connection starts with this value and adjusts it by watching the number
of frames that are ACKnowledged by the remote end. For example, if you
set a maxframe of 6 and your node has enough traffic queued, it will
send out a string of 6 sucessive I-frames. Your node now has 6
outstanding (that means unacknowledged) frames. If, on hearing the RR
(ACK) from the remote end, it only acknowledges 3 packets, WNOS will
drop the maxframe to this value since it guesses (it's a sensible guess
too) that 3 of the 6 frames sent were lost. As you can probably see from
this, if you kept a maxframe of 6 you would be wasting time with
retransmitting 3 out of every 6 I frames which is inefficient and
needlessly hogs the channel with data that is wasted.
WNOS actually implements dynamic maxframe by firstly setting the
maxframe to that specified by the "ax25 maxframe" command. After the
AX.25 T1 timer times out, maxframe is set to 1 and increased every time
if sent frames are ACK'ed within the lifetime of T1.
WNOS can resequence out of sequence packets. It quite often happens that
stations can send you data packets that are out of sequence. For
example, you were expecting frames 1, 2 and 3 but you got 1, 3 and 4.
Normally, most software will dump all but the first packet and
acknowledge it even if number 4 arrives quickly after. WNOS will hold 1,
3 and 4 for a time determined by the reassembly timer (ax25 t5) so if
packet number 2 arrives before T5 times out, it can reassemble them all
(1, 2, 3 and 4) and acknowledge all 4. Again, this increases efficiency.
WNOS can do hop-to-hop acknowledgement. On a marginal link using a
digipeater, it is often more efficient to have both halves (or all) of
the link operating in hop-to-hop acknowledgement mode. This means that
if, for example, someone digipeats via you, instead of digipeating the
packets on, your node opens a connection to the desired destination to
pass the packets on. Packets are therefore being passed using hop-to-hop
acknowledgement rather than digipeating. Again, this can increase
effeciency and throughput on marginal links (see that "ax25 digipeat"
command)
WNOS concatenates short frames. If, for instance, you type 3 short lines
(ie they total less than "ax25 paclen" in length), WNOS will concatenate
these packets and send them as one packet. A useful idea on a good link.
1.7.2. Memory Management
The old 'NOS provided' memory management routines have been replaced by
those provided by the Borland BCC (C++) compiler. The result is that
memory doesn't suffer from the sort of downward spiral always seen in
previous NOS versions.
If your system suffers heavy useage, the memory will of course drop
since each new connection opened requires memory to hold various pieces
of information needed (the Control Blocks). After these connections are
closed (and/or at regular intervals) the system will check the memory
for "holes" where memory has been freed but is too small to be used
usefully by something else. All these holes are then gathered together
and turned into one large chunk that can be used again. A process called
garbage collection and compaction.
If you run the "memory status" command at regular intervals during a
busy period, you should see the available free memory counter (coreleft)
drop. After connections close, you should, after a few minutes, see the
memory coreleft total creep up again. The result is that the machine
makes better use of memory and since it recovers as much memory as
possible, should last longer!
1.7.3. Setping
Setping is a small utility that allows WNOS to announce itself as an end
node in an TCP/IP network that uses the RSPF (Radio Shortest Path First)
routing system. It allows 'pings' (ICMP Echo Requests) to be sent to any
host at a regular interval. Note that the function is not exclusively
used for communicating with RSPF machines, you can use it to anyone
running TCP/IP software. WNOS keeps a table of how many replies it gets
to pings sent to each host and assigns a 'link quality' to that host
based on the percentage of replies that came back.
Typing the "setping" command will display all the hosts with whom you
have setping sessions active and the link quality of each. Hosts are
marked as "Bad" (host is most certainly down), "Suspect" (host is
probably down) or "Good" (the host is up). Setping sessions are stopped
with the "resetping" command.
1.7.4. Mode
The "mode" command has been extended to allow you to specify a
connection mode to any host individually. You no longer need to set a
default (and global) mode to reach all your direct hosts (eg mode 144 vc
- use AX.25 Virtual Circuits). Instead the mode to each host is
specified separately by its own "mode" statement. For example
mode g4otj 144 datagram g4otj-2
mode g4wrw 144 vc
mode g6den 432 datagram
mode [44.131.20.11] vc g4wrw-4
Note that the sytax of the command also allows a path to be specified
with the mode to each host.
1.7.5. Route Saving
WNOS will save to disk its routing information at intervals specified by
you (I use the defaults which are 10 minutes). Routing information saved
(and the corresponding files) is :-
IP Routing Table (route) - iproute.dat
AX.25 Routing Table (ax25 route) - axroute.dat
ARP Statements (arp) - arprout.dat
NET/ROM Routing Table (netrom route) - netrom.dat
This feature is very useful in that the complete system state is saved
when the program exits. Since you may have had connects from users for
which you had no route entered before (especially if a new user
appears), these will not be lost at the next startup. WNOS records ALL
pertinent information when a new connection to it is made (ie IP
address, interface, ax25 path or NET/ROM call and ARP entry if it was
used to reach you). This feature makes WNOS a truly dynamic system.
Note that all .dat files are *binaries* and so cannot be viewed or
edited.
1.7.6. Chat
The KA9Q/G1EMM/PA0GRI "ttylink" command has been replaced by "chat".
This sets up a session to a remote host's TTYlink (on TCP port 87). It's
just a shorthand for "telnet <host> 87" which would have the same
effect.
1.7.7. Mail and Node Activity Log
In WNOS you can selectively log activity on your mailbox and mail
server. Details of times and stations connecting to the mailbox will be
logged to the spool\node.log. Details of mail sent to and from the
system are logged in the file spool\mail.log. See the commands "mbox
log" for further details.
1.7.8. Socket Writes
You can send text out to any connection (known internally to WNOS by its
socket number) by using the "socket" command to find the socket number
eg 152. From the command window you can then type, for example
write 152 Hello John, This is Mike testing a socket write
the text specified will then be sent out on the connection which 'owns'
that socket. It is also very useful when logged in remotely to the
mailbox as sysop (See the Mailbox "@" command). When logged on as sysop
you cannot use any commands that start sessions (after all, how could
you send the screen updates and new window out to you ?). The socket
command is then useful for sending out a message to someone logged in
without starting a session.
Note that you cannot do socket writes to stations who are just using
your station as a digipeater.
You can also send messages to multiple users in the same way just by
adding the socket numbers you want to send to. For example (it's late
and you want to switch off and go to bed)...
write 152 144 163 176 Message from Sysop: System switches off in 3
minutes!
obviously much quicker than changing to all 4 sessions and typing the
same line into each one!
1.7.9. FTP Auto Login
WNOS3 takes the drudgery out of having to remember usernames and
passwords for use when logging in as an FTP user at a remote machine. In
the NOS root directory, you can create a file "nos.rc" which holds your
username and password used to login over FTP. Users of the Unix
operating systems will recognise the similarity with the ".netrc" file
used for the same purpose.
The format of the "nos.rc" file is....
<hostname> <username> <password>
<hostname> <username> <password>
etc
For example, if you use g0lxc as an FTP host, you might have an entry in
your "nos.rc" file with the line
g0lxc g6dhu mikechace
When you FTP to g0lxc, WNOS will login for you, sending the "user
<username" and "pass <password>" strings automatically. Once logged in
at the FTP host, you will see the ftp> prompt appear.
1.7.10. Domain Features
1.7.10.1. Domain Server
WNOS now has a built in domain server. This means, for example, that
other users, with no or small domain.txt files can query your domain
server for the IP address corresponding to the given domain name.
Say you use g4wrw as a domain server (ie you have domain add g4wrw...)
in your autoexec.nos startup file. You now type "telnet sys2.g6den".
Obviously, the first thing that happens is that your machine will search
the local domain.txt file for the IP address of the domain name
sys2.g6den.ampr.org. If it is not found, your machine will send out a
special "domain query" packet to g4wrw's domain server. It will then
search its domain file for the details specified. The results of the
query (success or failure) then get sent back to your machine. You can
then either procede (since you will have been told the IP address to
use) or, in the case of failure, the connection will be closed.
1.7.10.2. domain dfile
This command allows you to set a path other than the default (domain.txt
- in the 'root' directory) to an alternative domain file. For example
domain dfile d:/spool/domfiles/mydom.txt
1.7.10.3. BOOTP Server
This is really an extension of the "domain server" concept introduced
above. The BOOTP server is much like the domain server with the
difference in that it can supply any querying machine with ALL the
information it knows about routing and the domain. This means that a
querying machine can startup with little or no of its own IP or domain
information but have it supplied by interrogating the remote BOOTP
server.
On receiving a query, the BOOTP server supplies the querying machine
with a copy of its own IP route and ARP tables as well as a copy of its
domain.txt file.
Perhaps you can now see the reason for the name "BOOTP" since the server
supplies the "boot parameters" for the querying machine.
2. New NNTP Services
For those of you that use NNTP (Network News Transfer Protocol) to send
and receive news articles, WNOS3 provides both client and server with a
fully auto-configuring news system as well as a gateway that will
transfer bulletins handled by the SMTP server into the NNTP system as
news articles.
2.1. Auto Configuring NNTP System
The NNTP system within WNOS3 is now fully auto configuring. All you need
to do is supply the various NNTP parameters (see the "nntp ..."
commands).
News system sub-directories are automatically created if a new newsgroup
is handled and all NNTP system files (eg the active and history files)
are updated automatically.
Both server and client routines are included and you can therefore send
articles to others as well as collect new ones from your list of known
news servers.
The NNTP system files are also created (if necessary) on startup. These
are detailed in the "Files and Directory Structure" section below.
Obviously, if you are converting to WNOS3 from another NOS version
supporting NNTP you can just transfer all of your NNTP system files and
articles (after creating the appropriate article directories) and you
will be able to carry on as normal.
WNOS3 contains a simple, internal news posting program for you to be
able to compose and send news articles and transfer them into the
system. (See the 'nntp profile' and 'nntp post' commands)
2.2. SMTP -> NNTP Gateway
WNOS3 adds a new feature to the NNTP implementation. Mail messages,
usually but not necessarily, bulletins can be automatically sent into
the NNTP system by the SMTP server. For example, if another IP node
mails you all the AX.25 BBS bulletins sent to TCPIP@GBR, TCPIP@EU and
SYSOP@GBR via SMTP, you can transfer them into newsgroups, say
ampr.tcpip and gbr.sysop.
The SMTP server recognises a bulletin 'group' for transfer to NNTP by a
special notation in the Alias file (/alias). Alias entries are made as
normal but the name to expand to contains the newsgroup name preceded by
an exclamation mark (!).
Taking my example above, the alias file entries needed would be
tcpip !ampr.tcpip
sysop !gbr.sysop
The normal operation of the alias file isn't changed in any other way.
The bulletins are converted to NNTP news articles by the gateway and can
then be distributed to others using NNTP.
2.3. UK Version Notes
I have added the following features to DB3FL's standard release source
code for executables distributed by me to the UK.
2.3.1. NET/ROM Route Saving
Each time the 'netrom obsotimer' kicks, the program will save all netrom
routes to a file, "NRROUTE.DAT" in the WNOS root. The routes are saved
in plain text and maintain the status of the route (eg Permanent or
Recorded).
When WNOS3 is restarted, it will read the saved routes file and load
each route back into the internal netrom routing table. At present, no
check is made to age routes since they were last saved, each route is
initialised with an obsolesence count of 6. Obviously, any routes that
have since aged, will be slowly dropped in the normal way. All I wanted
to avoid by implementing this feature, was to stop having to wait for a
NODES broadcast from a local node to reload my netrom routes if I had to
take the system down for a short while.
I should also note, that this does not affect any netrom routes you may
set at startup either - they will still be read in too.
2.3.2. Forward Commands
I have also integrated G6PHF's code which adds the commands "forward
info" and "forward nic". These are used to set fields in a locally
generated Mailbox standard R: header which is added to all mail
(bulletins and personal) forwarded by the system onto AX.25. See the
Command Reference for details and an example of how to set the fields.
2.3.3. SMTP Header Stripping
Also integrated is G3UVQ's code to strip all SMTP headers from mail
forwarded from SMTP to AX.25. This is a useful addition to reduce the
size of messages sent into the BBS network or to PMSes, PBBSes etc.
Obviously, SMTP headers are retained on messages relayed, sent or
received via SMTP.
3. WNOS DOS Environment Variables
WNOS3 reads the following DOS environment variables
3.1. TZ
Timezone. Note the CAPITAL TZ! Sets the timezone to be used in
timestamping outgoing mail messages and for adjusting the machine clock
time to a local time. For example
set TZ=GMT+0UTC
GMT is the "official" inital timezone name. By official, I mean a
recognised name eg PST, UTC, CET etc.
+0 is the difference from the initial timezone.
UTC is the real (local) timezone name.
For a UK example...
set TZ=GMT+1BST
Meaning BST is GMT plus one hour.
The timezone string itself (UTC, BST, GMT etc) that you set is used to
stamp mail messages with the time when they were processed.
3.2. MAILER
Set the name and location of the mail program called by the "mail"
command
set MAILER=c:\tcpip\pcelm30.exe
4. Files and Directory Structure
The default files and directories used are...
alias # Mail Alias file
autoexec.nos # WNOS Startup file
arproute.dat # ARP statements (autosaved)
axroute.dat # AX.25 Routes (autosaved)
convers.cfg # Cluster Autoconnect file
domain.txt # Domain file
finger\ # Finger information directory
ftpusers # FTP and Mailbox user Permissions
iproute.dat # IP Routes (autosaved)
nos.rc # FTP Auto Login data
popusers # POP user and password file
spool\
\areas # List of mail areas
\forward.bbs # Mail forwarding instructions
\help\ # Mailbox Help file directory
\history # Bulletin ID (BID) history file
\mail\ # User Mail files (eg g6dhu.txt)
\mqueue\ # Outgoing Mail Queue
\news\ # NNTP root directory
\news\active # List of active Newsgroups
\news\history # NNTP Message ID history file
\news\junk # Newsgroups for junking
\news\pointer # Pointers to newsgroup storage directories
\news\poll # NNTP poll file
\news\xinfo # NNTP XINFO (site information) file
\rewrite # Mail Address Rewrite file
\rqueue\ # Mail Router Queue
\signatur\ # Mail signature directory
Directories are shown with a trailing slash, ordinary files without.
5. Source Code
Source code for WNOS3 will be available from me. You are in no way
restricted in passing the source code on to others. I would however ask
users passing source code to others the mail me with a message informing
me of who the code was given to. This is just so that I can keep track
of who has source code and pass on these details to Mike, DB3FL.
6. Bug Reports
As with all good software, it's hard to test 100% and so there are
likely to be a few bugs about.
If you find a bug please contact me with the details and I will do my
best to pass them onto Mike (DB3FL). WNOS has had a good reputation for
a fast response to bug reports and subsequent fixes.
Send me a good explanation of the bug and as good a grip on the
environment (both machine and the outside world) and circumstances in
which it takes place. Example autoexec.nos and any DOS batch files are
often useful too.
Please note that neither I nor Mike (DB3FL) will entertain bug reports
on executables that have been built from anything other than the
official release sources. Some users will have the source code - to
"roll their own" and if they change it and give you a copy of the
program built from those sources then direct your bug reports to them -
OK ?!
I can be reached in the following ways.
NTS Mailbox - G6DHU @ GB7IMB
Internet - mikec@praxis.co.uk
AMPRNet - mike@g6dhu.ampr.org [44.131.20.3]
Snail Mail - Mike Chace,
84 Frankland Close
Bath, Avon
BA1 4EL
73 and enjoy WNOS3!
Mike - G6DHU
7. Change Log
v1.1 30th November 1991 (WNOS3alpha10)
First Issue.
v1.2 4th Jan 1992 (WNOS3a9)
Added sections on NNTP system and SMTP/NNTP Gateway.
Second Issue
v1.3 31st Jan 1992 (WNOS3a9_1)
Cleanup a few point following comments from DB3FL.
v1.4 4th April 1992 (WNOS3b1_2)
Added bit about mail signature file.